Low power and Lossy Networks (LLNs), e.g., sensor networks, have a myriad of applications, such as Smart Grid and Smart Cities. Low-power and Lossy Networks (LLNs) may be used in a variety of applications (e.g. smart grids, smart cities, home, and building automation). Various challenges are presented with LLNs, such as lossy links, low bandwidth, battery operation, low memory and/or processing capability, etc. It is to be understood LLNs typically communicate over a physical medium that is affected by environmental conditions that often change over time. For instance, examples include temporal changes in interference (e.g. other wireless networks or electrical appliances), physical obstruction (e.g. doors opening/closing or seasonal changes in foliage density of trees), and propagation characteristics of the physical media (e.g. temperature or humidity changes). It is to be appreciated time scales of such temporal changes can vary widely e.g., between milliseconds (e.g. transmissions from other transceivers) to months (e.g. seasonal changes of outdoor environment).
It is further noted that low-cost and low-power designs limit the capabilities of transceivers in LLNs. This is because LLN transceivers typically provide low throughput. Furthermore, LLN transceivers typically support limited link margin, making the effects of interference and environmental changes visible to link and network protocols.
One attempt to overcome the above noted shortcomings was to use Record Route, which essentially is a method that records the path that a packet traverses within the packet itself. The Record Route not only identifies the set of routers/interfaces that a packet visits, but also the relative order. Existing protocols that specify Record Route functionality encode the path as a list of addresses/identifiers. Each node that forwards a packet with record route functionality is responsible for adding its own address to the packet before forwarding. It is pointed out a number of protocols utilize Record Route to help support routing and network management. For instance, IPv4 specifies Record Route functionality with IP option 7. IPv6 specifies Record Route functionality with IPv6 Routing Header 0 (now deprecated) and the RPL Routing Header (RFC 6554). Other protocols such as RSVP-TE (RFC3209) specifies Record Route objects (RRO) that operates similarly in order to set up Label Switched Traffic Engineering Label Switched Path.
Several routing protocols designed for mesh networking typically use Record Route (often called path accumulation) to support the route discovery and repair process. Proactive protocols may also use Record Route to inform the DAG root of the topology. In particular, routers generate and send routing control packets (similar to DAO messages in RPL) towards the root. Each router along the way adds its identifier to the Record Route list. When the root receives the message, it then has a complete path that it can use for source routing. It is to be appreciated that while early versions of RPL included Path Accumulation for DAO messages, recording full IPv6 addresses was deemed too expensive and dropped from the specification. Reactive protocols (e.g., Dynamic Source Routing) use Record Route functionality during the route discovery and repair process. In particular, when flooding a Route Request (RREQ), routers forwarding the RREQ add their identifier to the list. When the target receives the RREQ, it sends a RREP back to the originator with a copy of the recorded route. When the originator receives the RREP, it then has a complete path to the target that it can use for source routing.
However, since LLNs have limited resources which to operate with, Record Route mechanisms are often prohibitively expensive. The primary challenge is that each entry in the Record Route list must be large enough to encode the identifier. For example, when using 16-byte IPv6 addresses, a Record Route with ten hops will consume 160 bytes. Such overhead increases channel utilization, energy consumption, and latency while reducing overall packet success rates. Furthermore, this may require packet fragmentation, which is always undesirable. Another challenge is that some protocol architectures require the source to allocate the list within the packet, that is, routers along the way cannot expand the Record Route header to add additional entries. For example, IPv6 does not allow intermediate routers to alter the size of an IPv6 datagram, otherwise this would cause Path MTU Discovery issues.